Add Book to My BookshelfPurchase This Book Online

Chapter 7 - Building a TCP/IP Router-Based Network

Cisco TCP/IP Routing Professional Reference
Chris Lewis
  Copyright © 1999 The McGraw-Hill Companies, Inc.

Overview of Managing an Internetwork
Network management is one of the hot topics of the internetworking world. The idea of being able to control, optimize, and fix anything on a large, geographically dispersed internetwork from one central location is very appealing. Applications that enabled a network manager to monitor, troubleshoot, and reconfigure remote network devices tended to be vendor-specific until the Simple Network Management Protocol (SNMP) came along.
We should not forget that many of the functions of network management can be accomplished without SNMP. For example, we can use TFTP for configuration management, and Telnet for show and debug commands. (Common commands of this type are covered in the Chap. 8 section on "Troubleshooting.") The fact that documentation of a particular device states that it supports SNMP does not mean that it will fit nicely into the network management system you are putting together. We'll examine why in the next section on the components of an SNMP system.
SNMP System Components
SNMP version 1 is the most widely implemented version today. Network management applications that fully support SNMP version 2 features are only now becoming available. The basic subsystems of an SNMP v1 system are shown in Fig. 7-17.
Figure 7-17: SNMP system components
Let's start our discussion with the Management Information Base. The MIB is a database of objects arranged in hierarchical form, similar to that shown in Fig. 7-18. The exact numbering of leaves in the MIB tree shown in Fig. 7-18 is not important, because it is a fictitious tree; the issue is how the database stores, retrieves, and modifies values. Each level in the hierarchy has containers numbered from 1 onward. SNMP messages coming from a management station are of either the get type or set type. If a management station needs to determine the status of the device's Serial 0 port, it will issue a get command followed by the string 1.2.1.1. This period-separated value identifies the value in the MIB hierarchy to be retrieved. A management station can be used to set certain variables, such as setting a port from being administratively shut down to up by a similar mechanism of identifying the correct period-separated string for the variable that needs to be changed in the MIB hierarchy.
Figure 7-18: An example of a MIB hierarchy
If the documentation for a device tells you that it can be managed by SNMP, it may well mean that it has a MIB and a device agent (shown as the SNMP agent in Fig. 7-17) to interpret SNMP strings. Unless you want to spend hours writing programs to generate appropriate set, get, and other commands with the appropriate strings to follow the commands, you should check on whether the network management station application you intend to use has a management entity for the device in question. A management entity is software that resides on the management station and provides a friendly interface for the user to request information or set variables on the remote device. Cisco provides management entities for Cisco devices as part of CiscoWorks, its SNMP-based network management system.
Systems Management Objectives
There are many models for network management, and here I'll present the short list of what you can reasonably be expected to achieve with current network management tools.
  Centralized distribution of Cisco operating system software.
  Centralized configuration management.
  Event management for notifying an operator or other network administrator of the following: faults, attempted security breaches, performance failures (such as buffer overflow, overutilization of available bandwidth, excessive dropped packets, etc.).
  Log generation for audit and review purposes.
The big question when you're setting up a systems management system is: Do you collect information from remote devices by traps or by polling them? A trap is generated when a device agent becomes aware that a monitored event, such as an interface going down, has occurred. Collecting data via traps is risky, since it relies on the device and its line of communication to you being up and operational. Polls, on the other hand, are initiated by the network management station and proactively request information from remote devices. If the device does not respond, you have a pretty clear indication that something is wrong. The problem with polling every device on the network for status of all its monitored variables is that the traffic generated can become too high for the internetwork to support. This is a bigger problem the larger the network becomes.
Deciding how to split what you monitor via traps and what you monitor via polls is more of an art than a science, and it depends on the size of your internetwork, the interconnections in place, and the criticality of the various variables you wish to monitor. A reasonable starting point might be to poll key devices on a fairly infrequent basis, say once every 10 minutes, to check that they are functioning and accessible, then set traps for more detailed alerts, such as individual links to remote sites going up or down. If you really need to monitor specific MIB variables, such as dropped packets or bandwidth utilization, you have to poll the remote device for those particular values. This can place an unacceptable burden on the bandwidth available for user traffic on a large and growing internetwork.
We’ll revisit these issues in the section on the CiscoWorks management station. For now, let’s look at what we need to do on each router out in the field to bring it under the control of a centralized management system.
Sample Router Configuration for SNMP Management
The following commands taken from a router configuration file define the basics for enabling a router to be monitored from an SNMP management station.
access-list 2 permit 193.1.1.0 0.0.0.255
snmp-server community hagar RW 2
snmp-server packetsize 4096
snmp-server trap-authentication
snmp-server host 193.1.1.1 public
Let's explore these commands one by one, then look at some additional SNMP commands.
Command snmp-server community hagar RW 2 allows read and write access to hosts presenting the SNMP community string hagar if access list 2 permits it. The community string is like a password; a device wanting SNMP read and write access to the router will need to supply the correct community string. Access list 2 only permits packets from the 193.1.1.0 network. (It is assumed that your network management station is on this network number.) It is a good security measure to restrict SNMP access to hosts on your network management LAN.
Command snmp-serverpacketsize4096 raises the maximum packet size, which for SNMP communications defaults to 484 bytes—very small. It is more efficient in terms of network resource utilization to send a smaller number of larger packets than to send many small packets.
Command snmp-server trap-authentication works hand-in-hand with the snmp-serverhost command. By enabling trap authentication, you are telling the router to send an SNMP trap to the host address specified in the snmp-server host command. The trap is sent when the router becomes aware of any entity sending SNMP commands with an incorrect community string (i.e., one that is failing authentication).
Command snmp-serverhost193.1.1.1 public identifies the host address to send traps back to. If you want to send traps to multiple hosts, they must each have their own snmp-server host entries. The community string sent along with the trap is public, a default community string name. As it stands, this command sends traps of all types; optional keywords can limit the traps sent to specific types, such as tty (for when a TCP connection closes) or snmp (for traps defined in RFC 1157).
Some additional snmp commands you may wish to consider to expand the functionality of an SNMP monitoring system are as follows:
Command snmp-server queue-length can help handle situations where a router does not have an entry in its routing table to reach the management station, or is in a state where traps are being constantly generated, and a queue of messages to be sent out is building up. This command specifies the maximum number of messages that will be outstanding at one time; the default is 10.
Command snmp-servertrap-source specifies the interface, and by implication the IP address, to use for the source address when sending traps back to the management station. This could be useful if you know that all the serial ports on your internetwork routers belong to one major network number. You then can accept only those traps coming from this major network number and add some security to the process of trap collection.
The use of SNMP generally has been a good thing for people charged with managing internetworks. I recommend you use caution, however, when deciding which management station software to use, and be careful about deciding what you monitor via polling devices. Ideally, what you should look for in implementing a network management system is a minimum amount of traffic overhead placed on the internetwork, combined with operators being notified of monitored events on the internetwork as they happen. A network management station generally utilizes a graphical display of some kind, and uses visual prompts to notify operators of events on the internetwork. In most cases these events can trigger such things as e-mail and beeper notification.
I stated earlier that the optimal way to monitor an internetwork was to poll the most significant devices and set traps for all the ancillary devices and variable thresholds in which you are interested. With the management systems available today, achieving this is not always straightforward. Some management stations will not allow the status of a monitored device to be set when a trap is received. These management stations accept the trap, then poll the device to determine the exact nature of the trap sent. In other cases, the SNMP-managed device is a problem because some device agents do not allow traps to be generated for all the MIB variables that you want to monitor. In this situation, the only way to determine if a MIB variable that you have interest in has exceeded a given value is to poll the device and retrieve the MIB variable directly.
All this makes optimal management of an internetwork via SNMP a significant challenge. The key points to consider when purchasing a management system are summarized as follows:
  1. Will the management station respond appropriately to traps sent by monitored devices and not require a separate poll to be sent to the monitored device?
  2. Can you obtain device agents that will send traps for all the variables you wish to monitor?
  3. Can you set traps and threshold limits for all the variables you want to monitor simply by using a graphical user interface, without having to resort to programming arcane strings?
  4. If the management system suffers a catastrophic failure, can you use a text interface to manage device operation over modem lines?
Overview of Managing an Internetwork with CiscoWorks
CiscoWorks is Cisco's network management station software, which is supported on Sun Net Manager, IBM's NetView for AIX, and HP Openview platforms. CiscoWorks provides facilities for managing router configurations, notifying operators when specific events occur, and writing logs for audit purposes. CiscoWorks also has functions to help with performance and fault management. We will focus on the performance and fault management functions provided within the IOS user interface when we cover troubleshooting in Chap. 8.
The goal of this book is to introduce Cisco router technology to those with responsibility for, or interest in, internetworked environments. It is possible to effectively run and manage a Cisco router internetwork without a system such as CiscoWorks. When your internetwork grows to more than 60 or 70 routers, however, simple administrative tasks like changing the Enable password, or implementing a new configuration command on all routers, become onerous. This section provides a brief overview of CiscoWorks and how it can help monitor events and manage router configurations. The next section will cover loading IOS software on remote routers.
Figure 7-19: Top-level map display on HP-Openview
The foundation of the CW system is a Sybase database that keeps track of your internetwork's IP devices, their configuration, and selected status data. This database is presented graphically as maps on the management station display. Figure 7-19 shows a top-level map display for a sample internetwork. Typically, this top-level display will allow you to select a Point Of Presence (POP) location and display the detail of connections in that area via another map display.
Usually there will be several users of the CW system, which allows different usernames to be assigned their own passwords and appropriate user privileges. To set up the CW system, the internetwork either is searched automatically or devices are added manually. If devices are found automatically, it is done by IP address and you will want to modify the device type to be the specific Cisco router in use. Once you are satisfied that you have collected all the information, you will synchronize the CW Sybase database with the management system's database that you have installed.
The main benefits of CW are the ability to poll devices and receive traps to generate alerts for operators, and to simplify configuration changes through the Snap-In Manager tool, which allows you to set configuration changes for multiple routers on your network. The CW station can be used as the TFTP server for auto-install procedures and to retrieve remote router configurations on a regular basis for backup purposes.
CW notifies an operator of a network event—such as a polled device becoming unreachable, or an interface going down on a router enabled to send traps—by the color of the device's display changing from green to red. An alert box appears on the screen and, optionally, audio alarms can be set off.
It must be noted that running a CW system efficiently is not a trivial task; it requires substantial knowledge of the underlying management platform and the operating system on which it is running.
Router Software Management with CiscoWorks.     We have discussed using a TFTP server to store and download router configuration files, particularly for the auto-install procedure. Using plain TFTP will simplify things for you; some CiscoWorks applications will assist you even further. CW comes as a set of applications, the most useful of which we will overview here.
The CW Configuration Management application allows you to edit, upload, and download Cisco router configuration files. In general, the process involves creating a file by using a text editor, then executing the filetodatabase command in the configuration management window, followed by the databasetodevice command. This ensures that the Sybase database on the CW computer holds the most recent copy of the device's configuration.
The Configuration Management application has another feature that is sometimes useful in troubleshooting because it allows you to compare two configuration files and identify differences between the two. This can help in determining whether configuration changes made to a router have caused an internetwork problem. This is of value only if you have configurations for both before and after the internetwork problem started. Some users of CW systems perform an overnight backup of all router configurations, just for this purpose.
The Device Software Manager application simplifies the procedure for upgrading IOS or microcode remotely. This application actually consists of three applications: the Software Library Manager, to maintain and list the sources of software available; the Software Inventory Manager, to list current software status and sort device information according to platform and software image; and the Device Software Manager, to automatically upgrade the system software on a selected router. This software automatically performs all the tasks detailed in the section on remotely upgrading IOS from a TFTP server, which is covered in detail in the next section.
Global Command Manager allows you to automate the running CW applications such as upgrading devices or sending common configuration changes to routers. The application's concept is the same as that of the Unix cron utility. Any Unix or CW command that you can specify manually can be automated to execute at a specified time. The Global Command Manager can be used to schedule database tasks such as backups and purge of log files, device polling to retrieve MIB variable information, and use of the Configuration Snap-In Manager. For a command to be executed by this application, it must be created as a global command, which will add it to a log file of commands to be executed at the specified time.
The Configuration Snap-In Manager allows a common set of configuration commands to be sent to a set of devices. To use this application, define a set of commands as a snap-in, which can be applied to a defined set of devices. Snap-in commands must be of the same type; for example, you can send three snmp-server commands in one set, but you can't send an snmp-server and a logging buffered command in one set. The most useful things you can do with this application are to globally change the Enable password on your router configuration, and change security management station configurations such as access lists or source addresses.
Remotely Upgrading Router IOS from a TFTP Server
Different routers in the Cisco product line have different capabilities regarding the loading of IOS from a remote location. Some of the higher-end routers, such as the 7000- and 7500-series, have enough memory facilities to allow a new version of IOS to be loaded remotely, and the new IOS to take effect when the router is next booted or when a reload is issued. These routers also allow you to keep more than one version of IOS held in memory, in case you need to fall back to a prior version because of a problem with the new version.
In all probability, the most common router implemented in a Cisco internetwork is the 2500-series, because it is the cheapest and provides the functionality needed to bring a small remote office online to the corporate internetwork. One of the compromises in delivering a product like the 2500 is that it is limited in available memory. A 2500 router runs its IOS from flash memory rather than ROM. To upgrade the IOS in this type of router, the flash memory must first be erased, so that the new version of IOS can become the first file in flash memory and hence be the one from which the router is running.
To safely erase the contents of flash memory, you must be running at least a small operating system from somewhere other than flash; otherwise the router will stop running. This is where the Cisco Rxboot image comes into play. This boot image is a small operating system that runs from ROM chips on the router motherboard, and provides just enough functionality to boot the router with empty flash memory and load a new version of the IOS into flash.
Because the 2500-series is the most complex to upgrade remotely, and probably the most common device we need to upgrade remotely, we will examine its upgrade process in detail here.
The Rxboot ROM Program.     Rxboot supports Telnet and TFTP operations, but does not support routing, SNMP, routers with more than one interface enabled, TACACS, or IP unnumbered. These limitations have implications when you want to remotely upgrade router configuration.
The first step is to shut down all interfaces except for the serial port on which the router is to receive the new version of IOS. In addition, if the serial port normally uses IP unnumbered, it must be given a specific IP address prior to the upgrade process. Finally, the ipdefault-gateway command must be entered into the configuration of the router in global configuration mode, prior to the upgrade.
To execute an upgrade process, you must have a computer to use for Telnet access to the remote 2500, and a TFTP server somewhere on the internetwork that has loaded onto it a copy of the new version of the IOS. We covered TFTP server configuration in Chap. 3 when we discussed loading configuration files over a LAN. The same TFTP server configuration can be used for this purpose.
Preview of the Upgrade Process.     We will discuss each step in detail, but it is useful here to check a summary view of what we are about to do.
  1. Check that the TFTP server can ping the remote router to be upgraded, and configure the remote router to use a default gateway once its routing functionality has been disabled.
  2. Load the new version of IOS on to the TFTP server, ready for loading onto the remote router.
  3. Play it safe by completing a backup of the remote router's IOS and configuration file, should things go wrong.
  4. Reboot the router to use the Rxboot image, by loading its operating system from the ROM chips.
  5. Copy the new version of IOS to the remote router's flash memory and check that the checksum is the same as the file on the TFTP server, to ensure that nothing happened to the new version of IOS in transit.
  6. Boot the router from flash memory and check to make sure everything is functional before moving on to the next router.
Executing a Remote Upgrade.     Let's consider a situation in which a remote 2501 needs to have its IOS upgraded, as shown in Fig. 7-20.
Figure 7-20: Internetwork configuration for remotely upgrading a 2500 router
First, Telnet to the 2501 router and issue the following command:
2501>ping 193.1.1.1
Unless you get success at the ping level, you are not going to get very far, so it's worth checking this before we go any further.
Next, all serial ports other than the one we will use for the upgrade must be shut down and the ipdefault-gateway command entered, as follows:
2501(config)#interface serial 1
2501(config-int)#shutdown
2501(config-int)#exit
2501(config)#ip default-gateway 210.18.1.5
2501(config)#<Ctrl-Z>
2501#write memory
No change will be seen to the routing table of the 2501 router at this stage. The ip default-gateway command does not take effect until the routing process is disabled.
Loading the new version of IOS onto the TFTP server can be done many ways, from a software distribution disk, from Cisco's Internet site, or loading onto the TFTP server from a router already running the new IOS version. Whichever method you choose, you need to know the filename used. Let's look at saving the existing IOS to the TFTP server as a fallback consideration.
To save the IOS image file to the TFTP server, you must know the image filename, which can be determined by issuing the show flash all command. A sample screen output shown in Fig. 7-21 displays the router's IOS image filename, which in is 10_3_7.ip in this case.
Figure 7-21: Screen output of the show flash all command
The commands, subsequent router prompts, and responses to save this filename to the TFTP server are seen in Fig. 7-22.
Figure 7-22: Screen output of the copy flash TFTP command to save a router's IOS to a TFTP server
Now we start the real work. The 2501 router must be booted from ROM to use the Rxboot program as its operating system. To achieve this, the configuration register on the 2501 must be changed from 102 in hex, to 101 in hex, which is achieved as follows:
2501#conf t
2501(config)#config-reg 0x101
2501(config)#<Ctrl-Z>
2501#reload
At this stage, the Telnet session you have established to the router will be terminated while it reloads its operating system from boot ROM. For many, this is nerve-wracking the first time they attempt the process. Don't worry. Everybody has to do this for the first time once, and the process does work well.
After you give the router a few minutes to reload, you should be able to Telnet back in to it, and instead of the familiar login prompt, you will see the following prompt:
2501(boot)>.
To get into Enable mode, you will have to type the Enable password, and not the Enable secret. The Rxboot program does not recognize the Enable secret.
Next we want to load the new IOS from the TFTP server. Let's again play it safe by checking that the 2501 router can ping the TFTP server. Assuming that all is okay, we can proceed. If something has happened on the internetwork to prevent IP connectivity from the 2501 to the TFTP server, that must be resolved before we can continue. The new IOS is downloaded with the copy tftp flash command as shown next.
2501(boot)#copy tftp flash
IP address or name of remote host [255.255.255.255]?193.1.1.1
Name of file to copy? "New IOS filename"
Copy "new IOS filename" from 193.1.1.1 into flash address space? [confirm] <Enter>
Erase flash address space before writing? [confirm] <Enter>
loading from 193.1.1.1 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
The exclamation points indicate that a data transfer is in progress. The next stage is to verify that the file was transmitted successfully without alteration from the source. You can check this by verifying that the checksum shown at the end of the display from the copy tftp flash command matches that of the new IOS image as reported on the software distribution materials (either a disk, or as stated on the Cisco Internet site). If the checksum values don't match, again execute the copy tftp flash command. If after several attempts the checksums still don't match, try to reload the original file before executing yet again. If noisy line is introducing errors into the new IOS image as it is downloaded (remember TFTP uses UDP and not TCP, so there is no error correction), you should not boot the router from flash until the noise problem has been fixed and a good IOS version has been loaded into flash.
Assuming that the new IOS image is loaded successfully, you can return the router to normal operation as follows:
2501(boot)#conf t
2501(config)#config-reg 0x102
2501(config)#no ip default-gateway 210.18.1.5
2501(config)#<Ctrl-Z>
2501#reload
Once the reload has executed and you can Telnet back in to the router, you can remove the shutdown command from the Serial 1 port and the 2501 should be functioning with a new version of IOS.

 


 
Books24x7.com, Inc © 2000 –  Feedback